Amiga Format CD 24/Amiga Format AFCD24 (Feb 1998, Issue 108).iso/-in_the_mag-/emulation/uae/uae-0.4.3/readme.programmers

Text File | 1998-01-20 | 8KB | 127 lines

You can help to make this program better. If you fix bugs or implement new
features, I'd be grateful if you send me patches. For a list of interesting
projects, and for a brief summary on how UAE works, see below.

A few guidelines for anyone who wants to help:
- Please contact me first before you implement major new features. Someone
  else might be doing the same thing already. This has already happened :-(
  Even if no one else is working on this feature, there might be alternative
  and better/easier/more elegant ways to do it.
- Some coding guidelines.
  * Avoid GNU C extensions by all means. They make your code non-portable.
  * Avoid GNU indentation style by all means. It makes your code unreadable.
  * Try to indent your code nicely. There are editors like JED (I love this
    program) that do this for you automatically.
- If you have access to more than one Unix system, try compiling/running your
  code on all of these. Remember, UAE is supposed to run on the DEC Alpha: so
  don't assume sizeof(char*) == sizeof(int) == sizeof(long)
- If you have more than one Kickstart, try your code with each one.
- Patches are welcome in any form, but diff -u output is preferred. If I get
  whole source files, the first thing I do is to run diff on it. You can
  save me some work here (and make my mailbox smaller).

Here's my projects file - sorry, it's HTML.

<li>Someone with a 68000 data sheet might check whether all opcodes are
    decoded correctly and whether all instructions really do what they are
    supposed to do.
<li>Implement all 68020 instructions/addressing modes. [I might do that
    myself for 0.5]
<li>Improve the Kickstart replacement to boot more demos.
<li>Calculating the flags after each instruction is time consuming and usually
    completely unnecessary. Modify gencpu to generate instructions that don't
    set the flags, and have some code in the central loop to decide which
    set of instructions to use. This means additional overhead, of course,
    which might eat any improvements.
<li>Translate Kickstart ROM (or any software) to C code with a slightly
    modified gencpu, and link it to the rest of the emulator. Definitely
    possible, maybe illegal. Better don't do that for now.
<li>Make a modified gencpu that can generate x86 assembly instead of C. This
    might give a nice speedup. However, the CPU emulation already is the
    fastest part in UAE - screen updates are much more time consuming.
<li>Improve sound emulation.
<li>SVGAlib support could work better (SVGAlib itself could work a lot better,
    too, but that's SEP). Is there any way to use VC 7 like X does?
<li>Snapshots as in CPE. Will need to collect all the variables containing
    important information. Fairly easy, but boring. (Use core dumps instead
    :-)
<li>Make a better X interface - let's have some windows to control the thing.
    I don't think the debugger needs to be in its own window, but some
    graphical interface to eject and insert diskfiles would be nice. [I'm
    trying this right now]
<li>Find out why uae.device doesn't work with Kick 1.3. Not really important,
    no one in his right mind uses it anyway now there is the unixfs.device
<li>Make unixfs.device bootable.
<li>The playfield hardware is the only important part of the Amiga that is
    not really well documented in the HRM. Write some test programs that
    do all sorts of weird things with the copper (like turning off bitplane
    DMA during a line, and turning it directly on again: VERY interesting
    result) and try to emulate this perfectly.
<li>Figure out a diskfile format that supports every possible non-standard
    format.
<li>Translate basic blocks of m68k instructions to intermediate code that is
    interpreted instead of the actual code. Optimize it of course.
    (Not sure whether it would really be faster. But ARDI's Executor does
    a splendid job on translation. This should really help even if the target
    code isn't native).
<li>ECS support. I'm a little against this one. There's nothing really good
    about ECS except maybe 2MB chip and big blits. SuperHires will look awful.
    Productivity mode is not needed, since we can use interlace mode without
    flicker. This has a higher resolution than Productivity, and more colors.
    <br>However, if someone really wants ECS...
<li>Implement 68882 FPU.
<li>Implement 68551 MMU. (anyone got info on that?)
<li>Implement AGA support. First task: Find documentation for it (I do have
    some articles, but it's not very much).
<li>Reimplement Amiga OS. (Well-behaved) Amiga programs could then be made
    to use the X Window System as a "public screen". Of course, not all the
    OS would have to be re-done, only Intuition/GFX.<br>
    An AWM window manager would also be nice for a start :-)
<li>Translate instructions on the fly to native code, like Executor does.
    I'll NEVER try that one myself.
<li>Find some extremely clever way to optimize screen updates to use another
    strategy than brute force, but _without_
    compromising compatibility. I think this is impossible, but we heard that
    word before.

How it works

Let's start with the memory emulation. All addressable memory is split into
banks of 64K each. Each bank can define custom routines accessing bytes,
words, and longwords. All banks that really represent physical memory just
define these routines to write/read the specified amount of data to a chunk
of memory. This memory area is organized as an array of WORDs, which means
that those parts of the emulator that want to access memory in a linear
fashion can get a (WORD *) pointer and use it to circumvent the overhead of
the put_word() and get_word() calls. That is done, for example, in the
pfield_doline() function which handles screen refreshes.
Memory banks that represent hardware registers (such as the custom chip bank
at 0xDF0000) can trap reads/writes and take any necessary actions.
In some places, this scheme is abused: The uae.device and unixfs.device are
stored in a segment at 0xF00000 containing a ROMtag structure, so it is
recognized at bootup. Since this is a ROM area, writes shouldn't occur
normally and are therefore used to trap into emulation routines for these
devices.

To provide a good emulation of graphical effects, only one thing is vital:
Copper and playfield emulation have to be kept absolutely synchronous. If the
copper writes to (say) a color register in a specific cycle, the playfield
hardware needs to use the new information in the next word of data it
processes.
UAE 0.1 used to call routines like do_pfield() and do_copper() each time the
CPU emulator had finished an instruction. That was one of the reasons why it
was so slow. Recent versions try to draw complete scanlines in one piece. This
is possible if the copper does not write to any registers affecting the
display during that scanline. Therefore, drawing the line is deferred until
the last cycle of the line. If the copper writes to a hardware register before
that, the function pfield_may_need_update() is called and this one determines
whether it should fall back to the cycle-for-cycle approach. This is very
rarely needed, mainly for copper-plasma effects and such, and the general case
is much faster.

The CPU emulator no longer has to call all sorts of functions after each
instruction. Instead, it keeps a list of events that are scheduled (timer
interrupts, hsync and vsync events) and their "arrival time". Only the time
for the next event is checked after each CPU instruction. If it's higher than
the current cycle counter, the CPU can continue to execute.